Modelling the pacemaker in event-B: towards methodology for reuse

The cardiac pacemaker is one of the system modelling problems posed to the Formal Methods community by the {\it Grand Challenge for Dependable Systems Evolution} \cite{JOW:06}. The pacemaker is an intricate safety-critical system that supports and moderates the dysfunctional heart's intrinsic electrical control system. This paper focusses on (i) the problem (requirements) domain specification and its mapping to solution (implementation) domain models, (ii) the significant commonality of behaviour between its many operating modes, emphasising the potential for reuse, and (iii) development and verification of models.We introduce the problem and model three of the operating modes in the problem domain using a state machine notation. We then map each of these models into a solution domain state machine notation, designed as shorthand for a refinement-based solution domain development in the Event-B formal language and its RODIN toolki

Timing diagrams add Requirements Engineering capability to Event-B Formal Development

Event-B is a language for the formal development of reactive systems. At present the RODIN toolkit [15] for Event-B is used for modeling requirements, specifying refinements and doing verification. In order to extend graphical requirements modeling capability into the real-time domain, where timing constraints are essential, we propose a Timing diagram (TD) [13] notation for Event-B. The UML 2.0 based notation provides an intuitive graphical specification capability for timing constraints and causal dependencies between system events. A translation scheme to Event-B is proposed and presented. Support for model refinement is provided. A partial case study is used to demonstrate the translation in practice

Towards a methodology for rigorous development of generic requirements patterns

We present work in progress on a methodology for the engineering, validation and verification of generic requirements using domain engineering and formal methods. The need to develop a generic requirement set for subsequent system instantiation is complicated by the addition of the high levels of verification demanded by safety-critical domains such as avionics. We consider the failure detection and management function for engine control systems as an application domain where product line engineering is useful. The methodology produces a generic requirement set in our, UML based, formal notation, UML-B. The formal verification both of the generic requirement set, and of a particular application, is achieved via translation to the formal specification language, B, using our U2B and ProB tools

Retrenching the Purse: Finite Exception Logs, and Validating the Small

The Mondex Electronic Purse is an outstanding example of industrial scale formal refinement, and was the first verification to achieve ITSEC level E6 certification. A formal abstract model and a formal concrete model were developed, and a formal refinement was hand-proved between them. Nevertheless, certain requirements issues were set beyond the scope of the formal development, or handled in an unnatural manner. The retrenchment Tower Pattern is used to address one such issue in detail: the finiteness of the purse log (which records unsuccessful transactions). A retrenchment is constructed from the lowest level model of the purse system to a model in which logs are finite, and is then lifted to create two refinement developments of the purse, working at different levels of detail, and connected via retrenchments, forming the tower. The tower development is appropriately validated, vindicating the design used

Dynamic aspects of retrenchments through temporal logic

Refinement is used as a way to verify an implementation with respect to a specification. States of related systems are linked through a so called gluing invariant which remains always true during the synchronous execution of both systems. Refinement is a sufficient condition for this property. Retrenchment is a generalization of refinement which relax the constraints between both systems. This paper proposes a temporal logic counterpart for some specific forms of retrenchment

Feature-Oriented Modelling Using Event-B

Event-B is a formal method for specification and verification of reactive systems. Its Rodin toolkit provides comprehensive support for modelling, refinement and analysis using theorem proving, animation and model checking. There has always been a need to reuse existing models and their associated proofs when modelling related systems to save time and effort. Software product lines (SPLs) focus on the problem of reuse by providing ways to build software products having commonalities and managing variations within products of the same family. Feature modelling is a well know technique to manage variability and configure products within the SPLs. We have combined the two approaches to formally specify SPLs using Event-B. This will contribute the concept of formalism to SPLs and re-usability to Event-B. Existing feature modelling notations were adapted and extended to include refinement mechanism of Event-B. An Eclipse-based graphical feature modelling tool has been developed as a plug-in to the Rodin platform. We have modelled the "production cell" case-study in Event-B, an industrial metal processing plant, which has previously been specified in a number of formalisms. We have also highlighted future directions based on our experience with this framework so far

Modelling complex timing requirements with refinement

In the domain of formal modelling and verification of real-time safety-critical systems, our focus is on complex - i.e. nested, interdependent and cyclic - timing constraints. In Event-B, we present methodological support for our concept of timing interval by defining a set of refinement transformations, designed for structured modelling of such timing constraints. All timing interval related aspects are generated by our tool. An example development, abstracted from our work modelling a cardiac pacemaker, serves to illustrate the use of the transformations. The development is undertaken, proved and model-checked in the Rodin tool-kit for Event-B

Requirements Validation by Lifting Retrenchments in B

Simple retrenchment is briefly reviewed in the B specification language of J.-R.Abrial (Abrial,1996) as a liberalization of classical refinement, for the formal description of application developments too demanding for refinement. The looser relationships allowed by retrenchment between adjacent models in the development process may capture some of the requirements information of the development. This can make requirements validation more difficult to understand since the locus of requirements should be the models, and not their interrelationships, as far as possible. Hence the universal construction of (Banach,2000), originally proposed for simple transition systems, is reformulated in B, in order to "lift" a given retrenchment conceptually, thus retracting such requirements information back to the level of abstraction of the abstract, ideal model. Examples demonstrate the cognitive value of retracting requirements to the abstract level, articulated in a well-understood formal language. This is also seen to yield a more understandable way of comparing alternative retrenchment designs. Some new B syntax in the pre- and postcondition style is presented to facilitate expression of the lifted requirements

The engineering of generic requirements for failure management

We consider the failure detection and management function for engine control systems as an application domain where product line engineering is indicated. The need to develop a generic requirement set - for subsequent system instantiation - is complicated by the addition of the high levels of verification demanded by this safety-critical domain, subject to avionics industry standards. We present our case study experience in this area as a candidate methodology for the engineering, validation and verification of generic requirements using domain engineering and Formal Methods techniques and tools. For a defined class of systems, the case study produces a generic requirement set in UML and an example instantiation in tabular form. Domain analysis and engineering produce a model which is integrated with the formal specification/ verification method B by the use of our UML-B profile. The formal verification both of the generic requirement set, and of a simple system instance, is demonstrated using our U2B and ProB tools. This work is a demonstrator for a tool-supported method which will be an output of EU project RODIN. The method, based in the dominant UML standard, will exploit formal verification technology largely as a "black box" for this novel combination of product line, failure management and safety-critical engineering

Retrenching the purse: The balance enquiry quandary, and generalised and (1, 1) forward refinements

Some of the success stories of model based refinement are recalled, as well as some of the annoyances that arise when refinement is deployed in the engineering of large systems. The way that retrenchment attempts to alleviate such inconveniences is briefly reviewed. The Mondex Electronic Purse formal development provides a highly credible testbed for examining how real world refinement difficulties can be treated via retrenchment. The contributions of retrenchment to integrating the real implementation with the formal development are surveyed, and the extraction of commonly occurring ‘retrenchment patterns’ is recalled. One of the Mondex difficulties, the ‘Balance Enquiry Quandary’ is treated in detail, and the way that retrenchment is able to account for the system behaviour is explained. The problem is reconsidered using generalised forward refinement, and the simplicity of the resolution of the quandary, both by retrenchment, and by generalised forward refinement, inspires the creation of a genuine (1; 1) forward refinement for Mondex, something long thought impossible. The forward treatment exhibits a similar balance enquiry quandary to the backward refinement, as it must, given that both are refinements of an atomic action to a non-atomic protocol, and the forward quandary is dealt with as easily by retrenchment as is the backward case. The simplicity of the retrenchment treatment foreshadows a general purpose retrenchment Atomicity Pattern for dealing with atomic-versus-finegrained situations